Typically, as shown in FIG. 1, a wireless communication system 10 comprises elements such as client terminal or mobile station 12 and base stations 14. Other network devices which may be employed, such as a mobile switching center, are not shown. In some wireless communication systems there may be only one base station and many client terminals while in some other communication systems such as cellular wireless communication systems there are multiple base stations and a large number of client terminals communicating with each base station.
As illustrated, the communication path from the base station (BS) to the client terminal direction is referred to herein as the downlink (DL) and the communication path from the client terminal to the base station direction is referred to herein as the uplink (UL). In some wireless communication systems the client terminal or mobile station (MS) communicates with the BS in both DL and UL directions. For instance, this is the case in cellular telephone systems. In other wireless communication systems the client terminal communicates with the base stations in only one direction, usually the DL. This may occur in applications such as paging.
The base station with which the client terminal is communicating with is referred as the serving base station. In some wireless communication systems the serving base station is normally referred to as the serving cell. While in practice a cell may include one or more base stations, distinction is not made between a base station and a cell, and such terms may be used interchangeably herein. The base stations that are in the vicinity of the serving base station are called neighbor cell base stations. Similarly, in some wireless communication systems a neighbor base station is normally referred to as a neighbor cell.
High data rate wireless communication systems are deployed to address the growing demand for fast and mobile internet access. The Forward Error Correction (FEC) based on Turbo codes is one of the key factors in delivering highly efficient wireless communication systems that provide high data rate with limited Signal-to-Noise Ratio (SNR) and bandwidth. Turbo codes enable improved performance through iterative decoding process. The number of iterations required to successfully decode a block of data depends on many factors including the signal conditions (e.g., SNR), the code rate of FEC, etc.
The number of decoding iterations required in a Turbo decoder may be generally higher under poor signal conditions or at very high FEC code rates with limited redundant bits for error correction. To meet specified data rate requirements, a Turbo decoder may need to be designed for the highest throughput even under signal conditions and FEC code rates that require high number of iterations. This may require a Turbo decoder to run at a sufficiently high clock rate to complete all the iterations in the specified amount of time. For example, in 3rd Generation Partnership Project (3GPP) Long Term Evolution (LTE) wireless communication system, 150752 payload bits may be transmitted by a base station for every subframe (1 ms) to a Category-4 client terminal. This corresponds to about 150 Mbps data throughput. These bits may be transmitted in smaller independently decodable blocks called Code Blocks (CB) within a single subframe. In case of 3GPP LTE wireless communication system, the maximum Code Block size is 6144 bits as specified in 3GPP “TS 36.212: Evolved Universal Terrestrial Radio Access (E-UTRA); Multiplexing and channel coding”. Each Code Block may be individually encoded for FEC and Cyclic Redundancy Check (CRC). This means that about 150752/6144=25 Code Blocks of 6144 bits each need to be decoded in one subframe. As an example, if a Turbo decoder implementation supports a maximum of 16 iterations (8 normal order and 8 interleaved order iterations), the worst case number of iterations for all the Code Blocks may be 25 * 16=400. If a Turbo decoder requires one clock cycle for decoding one payload bit per iteration, the total maximum number of required clock cycles per subframe (1 ms) may be: 16 * 25 * 6144=2457600. This means that the turbo decoder may need to run at clock speed of about 2.5 GHz to be able handle worst case number of iterations. The actual clock speed requirement may be higher because it may not be possible to schedule the Turbo decoder for 100% utilization.
One of the methods for reducing the clock speed requirement for a Turbo decoder may be the use of higher radix Turbo decoder which can process more than one payload bit per clock cycle. For example, a radix-4 Turbo decoder may process two bits of payload data per clock cycle. Another method for reducing the clock speed requirement may be the use of multiple instances of a Turbo decoder working on a same Code Block data. For example, if there are four instances of a Turbo decoder, the required number of cycles may be proportionally reduced. Small initial overhead of setting up the Turbo decoder may remain about the same. Both of the methods above may reduce the clock speed requirement but lead to increased complexity which may in turn lead to increased power consumption.
For the example case of four instances of a radix-4 Turbo decoder, eight payload bits may be processed in one clock cycle. This may bring the clock frequency requirement of a Turbo decoder to under 300 MHz. However, this clock speed may be still too high, which may cause increased power consumption. Furthermore, the need for supporting worst case number of iterations may be rare. Therefore, the designed capacity of a Turbo decoder may be rarely used and yet it may contribute to increased power consumption.
Most Turbo decoders employ one or more of adaptive stopping criteria to stop performing further decoding iterations. One such criteria may be to check the CRC of a Code Block at the end of each iteration. If the CRC passes, then the Turbo decoder may stop performing further iterations on that Code Block. Another adaptive stopping criteria may include the detection of conditions where a Code Block may be unlikely to be successfully decoded regardless of the number of iterations. Despite using such adaptive stopping criteria, the worst case scenario of requiring maximum number of iterations in a subframe cannot be avoided.
Due to statistical nature of the signal conditions and the number of decoding iterations required, a Turbo decoder may require variable number of iterations and therefore variable amount of time to finish decoding all the Code Blocks of a subframe. If the decoding of one subframe is not finished before another subframe needs to be decoded, the processing of subsequent subframes may be delayed. Such consecutive delays can eventually cause excessive delays and the Turbo decoder may never catch up to the real time and be able to sustain the required throughput and latency requirements. Delay is a critical factor because the acknowledgement (positive or negative) may need to be sent to the base station in a timely manner for the Hybrid Automatic Repeat Request (HARQ) protocol to work properly. Therefore, even though on average the required number of Turbo decoder iterations may be low, a Turbo decoder must be designed to handle worst case scenarios over a sustained period of time.
Conventional methods for handling the Turbo decoder iterations requirement set an upper limit to the maximum number of Turbo iterations allowed for decoding one Code Block. Similarly, the maximum number of Turbo iterations allowed for an entire subframe may be limited to a value based on the implementation constraints. With the conventional method, if the turbo decoder completes the decoding of a Code Block in fewer iterations than the configured maximum allowed number of iterations, the time saved in unused iterations may not be utilized due to the static nature of the method.